Data protection and security is a multibillion dollar a year industry, yet data breaches happen frequently. This is due to many reasons: the inherent difficulty in protecting data, competing standards of protection, many different hardware and software solutions, as well as the greatly varying skill levels of the individuals or organizations implementing the protection. Thus, one of the most common ways is to simply protect the channel through which data passes (i.e., protect the phone line, etc). However, if the channel is compromised, then all the data may be easily accessed. The next logical step is to secure some, or all, of the data using a key.
Presently, symmetric keys are primarily exchanged in three ways (although variations exist): (1) encrypting the symmetric key using an asymmetric key before sending to the other side; (2) encrypting the symmetric key under a second symmetric key before sending to the other side; and (3) delivering the symmetric key using paper. Each of these common methods has a variety of problems. One of the most challenging problems is that a direct relationship must be established between the two parties to exchange symmetric keys. Establishing and managing this direct relationship is challenging, and the challenge is multiplied when keys expire quickly and/or many users are using the system. Other problems include slow transfer of keys (paper deliver), and/or obvious “break” points where the system has a weak point(s).
Even if the exchange of keys can be well implemented, the keys must be managed and stored securely. The management system must keep track of what key is used for which data. Typically, a given key may be selected to protect data based on business logic. Both the sender and the receiver must know what the business logic is to successfully determine what the key should be for a given piece of data. To do this, both sides must have a predefined relationship in order to exchange the necessary information about the key selection methodology and business logic. Problems with this implementation include a component breaking, encountering a bug or some other issue, which may result in the data being “lost” forever in an encrypted state.
For example, U.S. Pat. No. 8,295,492 (“Suarez”) is directed towards an automated key management system. Suarez is able to automatically generate cryptographic keys, as well as automatically distribute the keys. However, Suarez falls victim to the various flaws described above.